J2ME
Overview It is therefore up to the manufacturers to implement a JVM for their specific platform compliant with the JVM Specification and Java Language Specification. A configuration outlines the following: The Java programming language features supported The JVM features supported The basic Java libraries and Application Programming Interfaces (APIs) supported A profile defines a set of APIs which reside on top of a configuration and offers access to device specific capabilities. Definitions and Assumptions Configurations CDC Connected Device Configuration (CDC): targeted toward powerful devices like Internet TVs and car navigation systems CLDC Connected Limited Device Configuration (CLDC): targeted toward less powerful devices like mobile phones and PDAs Packages in CLDC java.io: Provides classes for input and output through data streams java.lang: Provides classes that are fundamental to the Java programming language java.lang.ref: Provides support for weak references java.util: Contains the collection classes, and the date and time facilities javax.microedition.io Classes for the GCF GCF The GCF is a replacement for java.io and java.net, and provides a generic approach to connectivity. The GCF is used to create connections such as datagram or stream connections. KVM CLDC defines a minimal subset of functionality from the J2SE platform. Hence, the CLDC does not define device-specific functionality in any way, but instead defines the basic Java libraries and functionality available from the Kilo Virtual Machine (KVM). The KVM got its name because it includes such a small subset of the J2SE JVM that its size can be measured in kilobytes. Profiles MIDP The Mobile Information Device Profile (MIDP) is a profile to be used with the CLDC and provides a set of APIs for use by mobile devices. These APIs include classes for user interface, persistent storage and networking. There are two version of MIDP Packages in MIDP-1 MIDP adds packages to the configuration packages. It also adds some classes to the packages of the configuration javax.microediton.lcdui: Provides classes for user interface javax.microedition.midlet: Defines MIDP applications and the interactions between the application and the environment in which the application runs javax.microedition.rms: Provides persistent storage (Record Management System) Device Requirements of MIDP-1 Display: 96x54 Memory: 128 KB of non-volatile memory for the MIDP components. 8 KB of non-volatile memory for application-created persistent data. 32 KB of volatile memory for the Java runtime environment Networking: Two-way, wireless, possibly intermittent, with limited bandwidth Packages in MIDP-2 MIDP adds packages to the MIDP-1 packages. javax.microediton.lcdui: Provides classes for user interface javax.microedition.midlet: Defines MIDP applications and the interactions between the application and the environment in which the application runs javax.microedition.rms: Provides persistent storage (Record Management System) javax.microedition.lcdui.game: Provides functionality useful for game development javax.microedition.media: Provides the Audio Building Block (ABB) javax.microedition.pki: Provides functionality for handling certificates Device Requirements of MIDP-2 Display: 96x54 Memory: 256 KB of non-volatile memory for the MIDP components. 8 KB of non-volatile memory for application-created persistent data. 128 KB of volatile memory for the Java runtime environment Networking: Two-way, wireless, possibly intermittent, with limited bandwidth Sound: The ability to play tones, either via dedicated hardware or via software algorithm Midlet MIDP applications are called MIDlets. Even though Figure 3.4 defines MIDlets as applications built using the MIDP and CLDC only, one usually also refer to OEM-specific applications as MIDlets. Midlet Suites MIDlets are usually available through MIDlet suites. A MIDlet suite consists of two files, a .jar and a .jad file. The Java ARchive (JAR) file contains compiled classes in a compressed and preverified format. Several MIDlets may be included in a MIDlet suite. Hence, the JAR file will contain all these MIDlet classes. This enables multiple MIDlets to share resources, like common libraries included in the MIDlet suite or data stored on the device. Because of security constraints, a MIDlet may only access the resources associated with its own MIDlet suite. This applies to all resources, such as libraries it may depend on or data stored on the MID. The Java Application Descriptor (JAD) file is a plain text file containing information about a MIDlet suite. All MIDlets must be named in this file, the size of the JAR file must be included (and be correct!) and the URL to the JAR file must be present. In addition, the MIDlet suite version number is included here. This is essential information for a MID. The MID will always download the JAD file first and inspect its contents. If the MIDlet suite is already installed, it will know if a newer version is available. The size of the JAR file is important information, the MID can determine if there is enough memory available to install the MIDlet suite. If all is well the MID can go to the supplied URL and download the JAR file. Other attributes may be included as well. Midlet vendor and other information may be included on a nice-to-know basis. OEM-specific applications OEM-specific applications rely on OEM-specific classes. Both Nokia and Sony Ericsson have their own classes for user interface and device specific functionality. E.g. vibration is provided through these specific classes. One of the main advantages of MIDlets is their portability. If you use OEM-specific classes you sacrifice this portability. Using Nokia classes will for certain give you an error if you run your MIDlet on a Sony Ericsson device. How-To Getting Started Skeleton of a Midlet import javax.microedition.lcdui.Command; import javax.microedition.lcdui.CommandListener; import javax.microedition.lcdui.Displayable; import javax.microedition.midlet.MIDlet; public class YourMidlet extends MIDlet implements CommandListener { public void startApp() { } public void pauseApp() { } public void destroyApp(boolean unconditional) { } public void commandAction(Command c, Displayable d) { } }